Глава 1 Введение

Design is a complex process composed of many smaller activities: listening, analyzing, evaluating, brainstorming, synthesizing, experimenting, composing, describing, discussing, exploring, reacting, and countless others. Documenting is not one of these activities, but engaging in any of these activities yields artifacts—diagrams, notes, sketches, lists, inventories, annotations, and larger documents—that result from the act of performing the task. At the same time, each task requires inputs, and these artifacts that come from doing design are the same things that can help feed the design process. The success of the task directly relates to the quality of the inputs, and may be measured on the quality of its outputs.

As a web designer, I don’t set out to create wireframes or flowcharts (two artifacts typical in the design process). My aim is to design a web site. These diagrams are merely useful tools in that endeavor, and I’d quickly discard them if more useful tools came along. This is an important point: Wireframes (or any other design diagram) may be the output of a design task, but they are not the product or the objective.

So, I like to think of design documents as both catalysts and by-products. Catalysts help facilitate a chemical reaction, and by-products are additional outputs but not the central or most important one of the reaction. Design documents contribute to the design process by facilitating creativity and communication, and they are a result of the design process itself.

Documentation contributes to the design process in many ways, but, ultimately, there are three reasons to produce it:

• Consistency of vision: As the design process explores deeper and more detailed aspects of the user experience, the team can easily lose the thread of the project. Design decisions at the deepest levels—obscure functionality, unlikely but possible user scenarios—may neglect the overall design vision. Yet good design depends on consistency because users count on consistent approaches to the user experience. Documents that capture that vision, those unifying themes, help remind the people working on the project of the appropriate direction. They give the project team the opportunity to evaluate new design ideas in the context of that vision.

• Insight: Drawing a picture of an idea gives the project team an opportunity to see that idea in a new way. Whether the idea is rendered in Adobe Illustrator or as a sketch on a whiteboard, the mere act of drawing the picture gives people something to react to, evaluate, and expand on.

• Traceability and accountability: Documentation is a paper trail, even if you never print out a single deliverable. By capturing the decisions as the project progresses, you have a record of the entire project and can see where crucial decisions happened and who made them. Reaching the end of a project, you may realize that you don’t remember why you did certain things—was there a reason for this button’s placement or that page’s unusual layout? Having a collective history in its documentation allows you to uncover the rationale behind these decisions.

Is formal documentation bad?

Documentation for its own sake is bad. A document that’s an item in a checklist is bad. Documentation without a purpose, without a clear role in the project plan is bad. In this case, “bad” means wasted time.

At the same time, documentation is inevitable, even if it’s a sketch on a whiteboard, a list of insights from a usability study, or a wall of stickies organizing content. In short, creative endeavors can’t help but produce artifacts. The choice you make as a design team is the extent to which you formalize these artifacts—that is, make them highly structured, polished, and playing an official role in the management of the project. The extent to which you formalize should be determined by need. Some reasons why you might formalize your deliverables:

• Distributed project teams need formal documentation to facilitate communications across space and time.

• Creative teams wholly separate from the business team (as in consultant-client relationships) need to prepare documents as part of a contractual relationship or to ensure they’re meeting their commitment.

• Projects with long timelines benefit from formality to ensure the longevity of design decisions.

Formalization takes time (though that varies from designer to designer depending on proficiency with the tools). Deciding whether the investment of time is worthwhile is up to the project team. With limited resources (people, hours in the day, budget, and so on) the team needs to determine where to focus efforts, especially if the same group of people may be responsible for multiple design activities.

One danger of an overemphasis on formal documents: You can end up spending tons of time and energy specifically on the artifacts and diagrams without keeping in the forefront how they serve the overall goal. I believe this is the reason that the user experience community flares up against documentation, and new methodologies are proposed that discourage extensive (or any!) documentation. When this happens it is an opportunity to refine and focus our understanding of the purpose of documents. Like any tool, documents can be misused. The greatest misuse of a document is to create it for its own sake, and not to ensure its contribution and value to your project, your team, or the end product.

The Whole Story: Deliverables

This book uses the term “deliverable” to refer to a complete stand-alone document. You can hand a deliverable over to someone completely unfamiliar with the project, and it tells enough of a story to bring him or her up to speed. A deliverable spells out context relative to the project, provides rationale for the ideas within, and explains how those ideas will lead to the next set of design activities. A deliverable tells a story by positioning the ideas it contains within the context of the larger project.

Deliverables are described in great detail in the second half of this book. That section leads off with a chapter called “Deliverable Basics,” describing the fundamental parts of a design document. It includes chapters on four other deliverables, dealing with specific communication challenges (Table 1.1).

The chapters in the first section describe diagrams.

Table 1.1. Four deliverables typical in the design process.

Parts of the Story: Diagrams

Individual diagrams are expressions of ideas and insights, but they don’t inherently acknowledge the larger context of the project. A diagram is like a scene or a vignette in a story: It may be entertaining and evocative on its own, but it comes with no context. A deliverable incorporates artifacts, just as a good story connects scenes in a way that evokes a particular theme.

This book describes five different diagrams, listed in Table 1.2.

Table 1.2. The five diagrams described in the first half of this book.

Отделение артефакта от продукта - это то, что я усвоил на протяжении всей своей карьеры, но это различие сформулировал Натан Кертис, мой партнер в EightShapes. При документировании дизайна вы будете переключаться между работой над конечным результатом и работой над диаграммами. Иногда обратная связь о вашей работе влечет за собой настройку элементов конечного результата, которые поддерживают артефакты, а иногда вам нужно изменить сами артефакты.

Содержимое результата поставки может быть независимым от артефактов, описывая цели проекта или нести сводную информацию из предыдущего результата поставки, обеспечивая контекст для того, где результат поставки вписывается в процесс проектирования. Контент может иметь прямое отношение к артефактам в поставляемом продукте, уточняя детали, предоставляя обоснование или устанавливая связи с другими артефактами.

Рисунок 1.1. Взаимосвязь результатов и диаграмм. Диаграммы вписываются в конечные результаты, но они являются якорями, которые можно использовать совместно, чтобы обеспечить контекст, ориентиры и преемственность. Диаграммы будут развиваться по мере того, как они будут использоваться в каждом конечном результате (а), или станут более зрелыми, когда созреет сам результат (б).

Инструменты для создания диаграмм и результатов

Эта книга не зависит от инструментов, и это просто причудливый способ сказать, что мне все равно, какой инструмент вы используете для создания описанных артефактов и результатов. Поскольку я знаю, что вы спросите, мои предпочтительные приложения в наши дни - это OmniGraffle от OmniGroup, Adobe InDesign, Apple Keynote и Apple Preview (для отображения и аннотирования PDF-файлов). Подавляющее большинство моих дизайнерских работ происходит здесь:

Независимо от инструментов, которые вы используете, книга делает некоторые предположения о них:

• Вы можете отделить диаграммы от результатов. Adobe InDesign великолепен в этом, позволяя встраивать файлы друг в друга. Файлы могут оставаться связанными, поэтому, если я изменю файлкоторый оказывается встроенным в документ, обновления будут отражены в документе. Это не значит, что вам нужно использовать Adobe InDesign. Вы можете использовать Microsoft Visio для диаграмм и Microsoft Word (или PowerPoint) для подготовки результатов.

• Вы можете создавать многостраничные документы. Как бы нам ни хотелось, чтобы наши диаграммы стояли сами по себе, создание конечного результата обычно означает рассказывание истории, в которой артефакт играет главную роль. Многостраничные документы позволяют более полно рассказывать истории.

• Вы можете относительно легко создавать диаграммы узлов и связей. Диаграммы узлов и связей - те, которые сводятся к фигурам, соединенным линиями, - составляют три из семи артефактов, описанных в этой книге. Его формат идеален для описания базовой структуры веб-сайтов.

Еще одно замечание об инструментах: не позволяйте никому указывать вам, какой инструмент является «правильным» для дизайна. (Если только этот человек не подписывает вашу зарплату.) Как дизайнер, вы несете ответственность за передачу своих дизайнерских идей. Найдите инструмент, который подходит вам в ваших обстоятельствах, и изучите его наизнанку. Вы полагаетесь на инструмент, который поможет вам в проектировании, но не женитесь на этом инструменте. Только для супругов. В тот момент, когда ваши задачи меняются, и инструмента становится недостаточно для воплощения ваших идей, отбросьте его и узнайте что-то новое.

Рисунок 1.2. Берите с собой ноутбук куда угодно.

Результаты и процесс проектирования

Методологии проектирования различаются с точки зрения теоретической основы, действий, общего подхода и процесса. Поскольку документация так тесно связана с процессом проектирования, набор результатов часто становится удобным способом определения конкретной методологии. Однако, по моему опыту, многие методологии опираются на определенные базовые документы - и проектные группы находят ценность в этих документах - независимо от методологии, которую они используют.

Тем не менее, в этой книге упоминаются три различных вида деятельности. Большинство методологий включают некоторые вариации этих концепций, если не сами конкретные действия:

• Понимание домена:Иногда вам приходится проектировать веб-сайт на основе содержания или функций, которые вам незнакомы. Например, веб-приложения, предназначенные для специалистов в области здравоохранения, отражают область, с которой большинство веб-дизайнеров не очень хорошо знакомо. (Если вы не врач, но тогда почему вы читаете эту книгу?) «Домен» - это свободный, но, как правило, обширный набор информации о конкретной области. Помимо базовой информации, любой домен имеет свой собственный жаргон, ярлыки для целевых аудиторий, уникальные отношения между контентом, функции, как важные, так и неясные, и множество других атрибутов, которые делают его уникальным. Как дизайнеры, наша задача - как можно быстрее освоить предметную область, чтобы мы могли применить опыт проектирования к решению сложных проблем, присущих предметной области. Моя точка зрения: в этом могут помочь результаты.

• Постановка проблемы:Большинство методологий основаны на предпосылке, что вы не можете создать веб-сайт, если не знаете, что ему нужно делать. Чтобы уловить эту потребность, дизайнеры и разработчики веб-сайтов определяют «требования». Требования обычно представляют собой набор утверждений, описывающих различные действия, которые должна выполнять система. Различные методологии делают это по-разному: одни методы уделяют мало внимания сбору требований, в то время как другие делают его центральным видом деятельности. Процесс документирования требований также сильно различается: от объемных электронных таблиц до рисунков фигурок и «историй» из трех предложений. В конечном итоге цель состоит в том, чтобы определить проблему, которую вы пытаетесь решить. Ваша методология может настаивать на том, чтобы у вас было полное определение проблемы, прежде чем пытаться ее решить. или он может признать, что вы никогда не сможете по-настоящему понять проблему, пока не попытаетесь ее решить. Независимо от вашего подхода, эта книга предполагает, что вы потратите хотя бы немного времени на то, чтобы выслушать клиента и провести некоторое исследование целевой аудитории, чтобы выяснить, что ей нужно.

• Решение проблемы: как только члены проектной группы понимают суть проблемы, они создают подход к ее решению. Для целей этой книги я предполагаю, что решение - это веб-сайт, который удовлетворит потребности бизнеса и целевой аудитории. Подобно сбору требований, эта деятельность варьируется от методологии к методологии. Некоторые требуют быстрых всплесков проектирования с последующим тестированием, в то время как другие призывают к расширенным циклам проектирования, перемежающимся периодическим тестированием, а третьи призывают к созданию прототипа и его доработке с течением времени. В этой книге предполагается, что вы используете проектную документацию (например, макеты и блок-схемы), чтобы определить, как будет выглядеть и вести себя конечный продукт.

Все эти действия составляют «разработку дизайна», и все они в большей или меньшей степени используют артефакты и результаты. Я не буду диктовать, что конкретные документы должны быть подготовлены как часть определенных действий, но это правда, что некоторые артефакты более подходят для определенных действий.

Выбор правильных результатов

Следует ли вам создавать все материалы этой книги для каждого проекта веб-дизайна?

Одним словом, нет.

В этой книге описаны типичные артефакты дизайна и методика их объединения в значимые результаты. Он определяет, как вы можете использовать один для предоставления контекста для другого, например, карты сайта, показывающие отношения между различными каркасами.

The book assumes, however, that you have planned for activities that yield these artifacts, but that you’ve selected those activities based on the needs of the project, not the kinds of outputs they produce (Table 1.3). This bears repeating: Choose activities for your project based on their ability to take you closer to an objective, not because you want to make a particular kind of output.

Table 1.3. Positioning deliverables in the design process. Design is about activities that lead to a web site, not activities that lead to wireframes and flowcharts.

The chapters are pretty explicit on appropriate circumstances for creating the different artifacts. They describe the activities that generally yield those documents. If your project plan doesn’t call for those activities but does specify those deliverables, you might re-examine the plan.

This is the best time to determine the appropriateness of different artifacts—during project planning. You don’t want to get to the “wireframing phase” (you should all be shuddering) and wonder at that point, “Why am I creating wireframes?”

Deliverables and the Project Team

Beyond methodology, project teams maintain an unwritten set of rules for working together. This is the project culture—an understanding of the value each team member brings to the table, how communications happen between team members, and the role of documentation in the organization. The dynamics between team members lead to potentially interesting challenges in creating documentation. And “interesting” is probably the best word for it.

The People That You Meet

The book frequently references “the project team.” This group of people includes anyone directly related to the project—decision-makers, designers, project managers, developers, and so on. Your company may have a finance person, for example, but his role doesn’t necessarily make him part of the “project team.”

• Designers or the design team: The protagonists throughout this epic, the people with titles like visual designer, interaction design, information architect, content strategist. These are the people who are most likely on the hook for creating and maintaining the deliverables described in this book.

• Project participants: Other people on the project, maybe not designers per se, but people heavily involved in making things happen. It’s a general term that can refer to everyone in this list.

• Project manager: The central member of the project team, the project manager runs the show. Different organizations use project managers differently, but for the most part, they have daily contact with the client and facilitate activities between the team members.

• Discipline leads: People who “own” particular aspects of the design or implementation. You may have five different designers on a project but one “creative lead.” The book assumes that with respect to design decisions, the buck will be stopping here-ish.

• Client: The organization financing the web site. Clients contribute one or more stakeholders.

• Stakeholders (such as product managers and domain experts): People who have a vested interest in the success of the project, perhaps because they own the project on the client side or they will be users of the web site or they have an intimate knowledge of the domain.

• Developers, engineers, and quality assurance: The people responsible for building and testing the stuff you design. They are, in a sense, your main customer. Even though they may not be buying design services directly, your process and outputs need to provide the right information for building the web site. One way I look at my job is how I can make their jobs easier.

Can one person play more than one role? Definitely. Can one person play all these roles? Yes, but he’s very, very lonely. And busy.

Team Dynamics

This book assumes, perhaps naively, that a good project team should be built on collaboration and consensus. Most projects fare better when they operate under the assumption that everyone wants to make a worthwhile and meaningful contribution and that people should feel some ownership for their work. Such an approach comes with potential risks: Ownership can become about ego, decision-making takes longer, innovation doesn’t happen in groups. A group committed to a successful project needs to take steps to mitigate those risks.

Good designers (author’s opinion here, based on years of experience) learn the dynamics of the project team, observing:

• Collaboration: Some teams are structured to encourage collaboration. They insist that designers work together to establish big ideas, review the details, and provide almost a constant stream of criticism. Other teams bring designers together more infrequently, and perhaps in a more formal way.

• Transparency: Making the sausage, opening the kimono, and a host of other slightly inappropriate metaphors all refer to the same thing: How much does the team expose the dirty underbelly (another one!) of the design process? Some design teams are happy to share works in progress, quick sketches, and not-yet-fully-formed ideas with each other and with the rest of the project team. Other teams take more of a “black box” approach, hiding their efforts until they have something fully formed.

• Disparity in hierarchy: Watch an episode of AMC’s Mad Men and you’ll see hierarchy at the workplace. It represents the 1960s in the advertising industry as structured and divided as feudal England. Strong hierarchies may have somewhat arbitrary rules for reviews and approvals of deliverables before they “go out” (get sent to project stakeholders). The other extreme would be a place so relaxed that they don’t even require second pair of eyes on a deliverable (scary thought).

• Strength of leadership: Being a leader on a design team implies many different things. Good leaders establish and stick to a vision. They provide meaningful and actionable critiques. They know what it takes to get from the current state to a worthwhile conclusion. Strong leaders—those who do these things well—establish a role for documentation on their projects. They understand how deliverables support their vision and advance the project toward objectives.

• Respect for clients: With any design team, the elephant in the living room is their relationship with their clients. While you may know about web design, they know their business, and both are needed for the project. I’ve heard horror stories of design teams creating web sites disparaging clients they don’t like.

• Respect for users: Those of us who subscribe to a user-centered design philosophy seek to understand how people will use the products and web site we design. This drive to understand them doesn’t automatically entail respecting them. Design teams and clients alike, as part of the design process, may generalize about their users, a recipe for breeding disrespect, thinking of users as incompetent, ignorant, or worse.

• Strategies for conflict: Teams employ particular approaches for dealing with conflict. Teams ill-equipped to resolve conflict may be unprepared to work in highly collaborative environments. This changes the role of documentation.

Understanding these dynamics is crucial because they affect how you prepare, position, and present your documentation. These topics could fill a book by themselves, but for now design teams can determine an approach to their documentation based on these dynamics by looking at:

• Clarifying the role of documents

• Establishing a vision and design principles

• Agreeing on a project plan

• Defining project ground rules

Navigating Politics

Politics hamper design by quashing voices of reason and enabling arbitrary design decisions. When design is subject to politics, design decisions are made without regard to external requirements.

This isn’t to say that strong personalities or leadership wielded with a heavy hand can’t do good design: Designers who have internalized external requirements, who maintain a consistent vision, and who have a rationale for their design decisions can be both successful and difficult to work with.

Client Relations

The client is the person or group of people who identified the demand for the product and seek to fill the demand. They’ve asked you, the designer, to help them create a web site to do just that. They are the ones who bear responsibility for the product and who finance it. They’re the ones who have to deal with the logistics, support, and deployment of the web site. They, at once, have a broader view (the logistical, business, and financial ecosystem in which the product lives) and a narrower view (their business and the product, and not necessarily any other relationships).

This book is about working with people with these perspectives as much as it is about working with people with the same perspective as the designer. Good documentation must communicate something abstract—the design of a web site—to this larger group of people, each of whom regards the design approach from their unique perspective. Good artifacts accommodate these alternate views of the product, at the very least recognizing that other members of the project team will be evaluating the deliverables from a different vantage.

The relationship between a design team and its client is crucial, and again has a dramatic impact on the deliverables. In addition to considering the dynamics listed earlier, project teams can assess the relationship between the designer and the clients along a scale (Table 1.4).

What about “innies”?

The content of this section is very much focused on my experience, being a consultant external to a client. My relationship with many different internal design teams has shown that they have a similar scale, one that measures their integration with the entire organization. Design teams can be carefully integrated into every aspect of a firm’s operations, or could be siloed, expected to “do the web site” and nothing more.

Like outside consulting organizations, internal design teams should have an objective: What kind of relationship will let them do design most successfully? With this objective in mind, teams can shift the approach for their documentation to begin to build that kind of relationship.

Describing vs. Doing

Do documents and design artifacts reflect “real work?” How much progress are you really making on the project by tweaking line weight on a wireframe or typography on a persona? How much does the design vision depend on your formalizing a deck of screen designs or creating PowerPoint presentations about personas?

Documentation can feel detached from the design process. Diagrams are abstractions of ideas that are in and of themselves abstractions. If we need to describe something that isn’t a direct reflection of a screen design (a site map, for example, or a visualization of the underlying assumptions), the documentation can feel even more detached. At least once on every project I push my chair back from my desk and wonder aloud, “What am I doing?” (Basement offices are the best places to wonder aloud. And listen to unpopular music genres.)

These moments of doubt are useful. They keep us honest relative to our process and force us to renew our commitment to great design time and again. Stepping back and giving documentation a critical eye, I give myself a chance to validate my efforts and make sure I’m contributing to the design in a meaningful way. I look out for at least three things:

• Is the level of effort on the deliverable on par with the utility derived from the deliverable? Spending hours upon hours on a document that won’t see the light of day beyond a single meeting may not be worth it… unless that meeting is meant to secure funding for the rest of the project. Spending a morning on a document that will drive and inform the design process for months to come may set the stage appropriately, but likely isn’t commensurate with its value.

• Am I having more fun making the document or working through the design problem? I love making diagrams. I love making diagrams that speak for themselves. I love making diagrams so much that sometimes I forget why I’m making them. The joy should be in solving the real design problem. If I’ve lost sight of that context, perhaps my efforts will be better served elsewhere.

• What I can I be doing that better reflects the final product? If I’m working in a diagramming program because that’s what I always do, I may be neglecting another approach that does a better job of demonstrating the design concept. Paper prototypes or animated PowerPoint slide transitions, while “less sexy” than polished diagrams may describe the design idea better.

Just one more philosophical reflection before you dive into the practical stuff. If I were to boil controversies about design methodology down into a single topic, this would be it. Our urge, as designers, is to get closer to the product, to be a craftsman who can effortlessly float between imagining and building. As products, production processes, and demand change, we create a greater disparity between the people who can think of good ideas and the people who can implement them. The urge to get closer to production encourages us to revisit our design processes, techniques, methods, tools, and communication mechanisms.

Table 1.4. Your relationship to the client team will affect the process and deliverables.

Вы собираетесь прочитать о нескольких различных схемах и методах объединения их в рассказ. Эти артефакты, небольшие проекты сами по себе, абстрагируются от конечного продукта. Тем не менее, хотя конечный продукт может ни в малейшей степени не ссылаться на них, этот продукт зависит от этих артефактов с точки зрения его концепции, дизайна и реализации. Поэтому они открыты для интерпретации, обсуждения, улучшения и развития, чтобы наилучшим образом удовлетворить потребности продукта и команды, ответственной за его создание. Приведенные здесь рецепты - это отправные точки и рекомендации, готовые для вас, чтобы вы могли формировать их с учетом собственных потребностей, обстоятельств и собственного опыта.